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MEmOD AND APPARATUS FOR MnMBV t. .-,pTT 
Tllb tar««ia. ^ „ ^ ^^^^^ 

5 limited excbsively to this. 

Money t™.sfa «rvic« ,„= oftied Iqr a ™,nU«r of o,prt«^ 
b«±s.fl«M««,gnunofl^ao«.a,Kltf.,W««„.U,tfo.oii,Btf^ A«i«ft« 

> banlc, for example, in a difibiem coimtiy. 
techniques suffer firom certain problems: 

0 Mortification of tiietnmsfe^e. Nonnally, a ,nmsfe„^ wiU be requi^d to 
pn«»tp»of of identification, for example, a passport or driving Ucence. before being 
pennitted to collect the funds. However. the« a« a la,^ mmO^r of coontries hi 
which many people do not holds pas^rts or o±cr officially recognisable pnH,f of 
Identification. 1° such cases, money transfer may be Hmhed to postal tnmsfeis. 
Western Union oflen. a code-won! fecility by which a tnnsfeior can pn,vide a code 
word witii the hntial transfer mstiuctions. ^ tiansfen^. is to present a 

matchmg code word mstead of presenting proof of idemification. 
(iO Security. Particularly when a code word is 

tnnsferee. or oti«r parties hr^lved ta the money t.««ffer 
ft wiU be appreciated ti«a. espec^dly m certdn com^ 

commonplace, and dilficnh to control fiom outside ti« com^^ In general, die 

tiarisferee. and ti« baric staff fa, tire comnry of tire tra^^ 

h«re access to tiie code word and suffidem oti«r mformation to colter 

tocompteteti^transactionCsincenoproofofidentityisrequired^ Such fiai«i is very 
difficult to detect and to prevent 
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pardciilaily when unfamiliar pronunciation is involved^ or if two people are not fully 
conveisant in the same language* For exanq>Ie» if a the name of the tiansfisiee is 
misspelt, ifaim it may be inqx>ssible for die conect tiansferee to collect the funds even 
on piesratation of piqper identification. Such a ccnnmon error can cmly be conected 
5 by the transferor complaming to the transfer organisadon, when he is notified of the 
mm-deiivery by the transferee; the full transfer details have to be tak» again from die 
transferor to attempt a further tiansfw. 

The present invention has been devised bearing the above problems in mind. 
Broadly speaking, a first as;^ of the invention is to provicte tte transferor with 

10 a secret identifier code (referred to in preferred embodiments as a party identification 
code or PIQ wliich is sqiplied to the transferor indepmd»tiy of the mformaticm 
exdianged widi the transferor whra die transferor is makmg a transfer reqoest (for 
exanq>le, m die preferred embodiment, die PIC is sent to die transferor by post). The 
identifier code (or at least information related diereto) can be transmitted as part of die 

15 money transfer instructions tfarougji the money handling audiorities. The transferor is 
reqpiired to transmit die secret identifier code to the transferee, and the transferee is, m 
turn, required to presrat die ktaitifier cocfe as one of the conditions to be met before 
the moi^y can be collected by tte transferee. Pdssessk>n of the conect identifier by 
the transferee rq>resents proof that the transferee has been authorised lo receive funds 

20 by the transferor. 

As used herein the term '^money handling authority* refers lo any authority 
ooopowered to handle nKmey and, where appropriate, refers to any audiori^ 
aD|x>wered to provide foods to a tiansferee. Hie term may include, but is not limited 
to, banks, internet banks* post offices, etc. 

25 Such a technique can avoid die need for die transferee to possess ofBdal proof 

of identification* and can also mq>rDve security. In particular, the local handling agmts 
at the point of sale to the transferor will not have access to suffidrat infmmatiiHi to 
receive the funds ftamittlently. 
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Preferably, the identifier code (PIC) is aOocaied for at least one of the ponies to 
the transfer (i.e. the transferor and/or the oansferee). In the prefened «niwvifm^ 
die identifier code (PIQ for the transfiaor, and the same 

transfers firan the tnuisferor to aiv transferee. This avoids die need forncw identifier 
codes to be issued to die transferor for each transaction. 

Broadly speakmg, a second closely related aspect of the invention is to generate 
an identifier code (referred in preferred embodiments as a unique transaction code or 

im:). and to proWde the transferor with the code (to be forwarded by die transferor lo 
the transferee), bat provide die money handlmg andioiity instnicted to handle the 
transfer widi second code (refened in the prefened embodimoits as a transaction 
verification code or TVQ related verifiably to die identifier code. The second code Is 
sufBcient to enable die money handling aodiotity to verify diat die transferee is 
andioiised to receive die fends upon presentation of die complete code by die 
Hansferee. Upon collection of die fends, die money handlmg andiority can 
complete identifier code dirough die bankmg system, as evidence diat die fends have 
been collected by die andiorised transferee. 

Snch a technique can provide security against a fiaudnlent -coUection" of die 
transfer by die money handlmg audiorities instructed to handle die transfer, since die 
money handling staff will not have access to die complete identifier code to comptete 
validly die transaction by rcuiraing die fell code as evidence of completion. If die 
fends arc collected fiaudukmly by a person who has knowledgB only of die second 

code (i.e. die TVQ, and has dierefore had to add a guessed code to die known code. 

tfUs wiB be readfly noticeahte when die incoirect code is received hack firan die moB^ 
handling audKNti^. 

Preferably, dus aqiect of die invention ferdier comprises testing, at least 
selectively or on demand, die foU Meotifier code hifonnatioB retumed fbr each 
completed transfer agamst die originally allocaied identifier code to verify tint die 
cwrect transferee has collected the funds. 



^•^OCte^'^'O 992S872A2 I : 
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Ahfaoagh tfae atxnre aq)ects can be used indq)ei)dently, paitkolar advantages 
can be adiieved by using tf^ two aq)ects in combination^ In patticolar^ tfae tecbniqae 
can then msuie that neidier tfae faandling agods at tfae point of sate, nor tfae handfing 
agents at dte ponit of coUection« possess aU of tfae necessaiy uifonnaiicm property to 
5 conq)kte a tiansfer. Only tfae transferor and titt transfeiee possess tte necessary codes 
(Le. die PIC idotifier code of die first Bspect, and the UTC identifier code of die 
second aspea) nee^ to ccmiplete tfae transfer. 

In a closely related zspect^ tfae invention provides a method of generating a first 
identifier cocte (UTC in the preferred onbodimrats) and a second code (TVC in tfae 
10 preferred embodiments) related thereto, tfae metfaod compriang: 

generating die first code such diat at least one cbarader diereof represents a 
fencticm of one or more otfaer diaractera of tfae first code; 

generating a seccmd code con^prismg at least one, bat not all, of die cfaaracters 
of tfae first code* and con^nisnig infbnnatioa nidicative of die pdsiticm in said first code 
15 of said at teast one cfaarader amd/or of said one or more other diaraders. 

l^ferd>ly» tfae dbaractm of dtt first cocte are numeric* 

Preferably, tfae fimction is a diecksnm (or sum) fimctkm. 

Preferably, die second code con^rises one or more ''blank'* characters 
representing ndssmg diaracter or digit poshions of tbe first code. 
20 Preferably, tfae function is based on diaracters in one or more predetermined 

positions in d^ first code, and said information rq>resents the portion m said first code 
of tfae result of tiffi fimction* 

In tfae preferred embodiment, the functicHi is nomerfe sum function of tfae first, 
fimr di^ in tfae first code, and tte infoimaticm idoitifies where tfae result is to be 
25 feond in die last four digits of tfae first code; a first diarader (*F*) denotes diat die 
resnh is in tfae first <me or two digits of tfae last ftor; a second character ("M**) denotes 
dot the result is ui the middle one or two digits of the last four; and a third character 
CL*) denotes diat tfae resoih is in the last one or two digits of the last four. It will be 
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api^dated that Other ind«iE^ 

munbcr of character positions available for tte result 

In a ctosely idaied a^ ,be inventkm piuvides a method of testiDg 
iirfbnnation pKiWded 1^ a transferee for col^ 

nxeiviDg transfer instiuctions iBdudh^ 

at least one of tl« partes 10 the trai«fcr. and a second trans^ 
nslaied 10 a transaction Identifier code allocated to riMj transac^^ 

(a) the fim pany identifier code fiom the transfer h«^^ 
party identifier code provide by the transferee; and 

(b) comparing tbt second transaction verification code witfi a transaction 
Identification code provided by die transferee. 

Picferably. tite meti«d fimher comprises remnting tite transaction identification 

code to tite issuing anU««^ as evidence dm dte transfi»ec is autf^^ 
fimds. 

fteferaWy. die transaction verification code comams some, but not all of dte 
(Wra of the transaction idemification code, and d» med«Ki co^ 
each known character b die transaction verification code for cqoivatoKy wifli a 
coirespondhig character of the transaction identifier code. 

ftefeiaWy. die transaction verification code inchides infonnation associated 
widi die result of a fimction based on one or more characters of dte transaction 
Mentification code, and d« medHxi comprises testing whedter dte transacdoii 
"tentification code presented by dte transferee matches dte fi^ 

h. a closely related a^ tfKt invemion provides a money transfer s^ 

cooqjrising: 

at least one remote input milt operable to gemaate a money transfer reqwst in 
accordance widi mfoimation fiom a transfeior; and 

Pn«alng means for commmticating widi each remote mA 
P«oce«mg money tnmrfer requests received dterefiom. dte processmg means 
comprisiiig: 



.9fle8872A2J_> 



SUBSITTUTE SHEET (RtlLE 26) 



wo 99/28872 PCr/GB98/03537 

6 

means for providiiig a first identifier cxxte associated widi tfie transaction and/or 
witii tl^ identity of oi^ or more parties to ti» transfer; 

means for cwH)«tting first infonnatiwi including die first identifier code, to be 
comnwinicated directly or indirectly to tbt transferor indepradendy of tte 

5 conummicatioii widi tbe tmninal; and 

means for ompotting second infimnation to be sqpplied direcdy or indirectly to 
a money handling autiioiity as instnictkms to effect tl» transfo* fN collection, the 
second information including at least a pordon of the first identifier code or infom^ 
related thereto to enable die authority of tte transferee to be verified. 

10 Preferably, die systrai inchicfes a phnality of tenninals. Preferably, the 

IMTOcessing means (also refeired to herun as the server), is ^le to craimunicate with 
each terminal at various times dhuing a woiidng day, to control the tenmnals direcdy, 
or to iq>load transfer re^iests (and ai^ odier uiformation) logged hy the teimmals whfle 
off-line (if off-line operation is siqiported). 

15 hi a fimher dosdy related aspect, the mvention provides a mon^ transit 

system craoprisingr 

at least one remote iqpnt unit operable to generate a money transfer reqpest in 
accordance with infoimation fiom a transferor; and 

processing means for communicating with each rraiote unit for receiving and 
20 processing money transfer requests received tiberefiom, wl^ein: 

die traninal and/or die processing means is qierable to ou^mt for 
communication directly or indirectly to the transferor, an identifier code allocated to 
die money transfer; and 

. die processing iMans is operaUe to ootpux money transfer instiucdons to be 
25 sqiplfeddirectlywiiidbecdy to a inoneyhandluig authority as Instructi^ 

transfer for collection, the instructions inclncBng only a first portion of the identifier 
code, whereby the money handling audiori^ can verify a pwdon of the Idmtifier code 
presented by the transferee. 
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Preferably, the tenninal is opeiabte to output tbc 

Prcfen*Iy, the tenniial is operabJe to commniiicate the i(te^^ 
processmg means. 

Piefeiably. the system compiises means for receiving a fidl Identifier code 

letmed by Ite money handUngawhoiily as evidence of completion of Ae transfer, and 

means for comparing the rennned idemificr code witfi the originally all^ 
die transaction. 

Preferably, the system comprises database means for storing die identifier code 
allocated to each transaction. 

An embodhnem of die mvemion is now described, Iqr way of otample only, 
widi reference to die acconqxmymg dxawmgs. m which: 

Kg. 1 is a sch«miatic block diagram ilhistntmg die princ^ 
embodiinrat; 

Kg. 2 is a schematic diagram ilhistrating die mfomiation used m Kg. 1; 

15 3 i» a schematic diagram ilhisirating generation of a UTC and a TVC; 

Kg. 4 is a schematic block dfaigram of a remote mpot unh; 

Kg. 5 is a schematic bkx* diagram of die central server; 

Kg. 6 is a flow diagram iUustrating operation of die central server; 

Kg. 7 is a flow diagram Ohistnting operation of die secout endxxfiment of 
20 teiminal; 

Kg. 8 is a flow diagnun ilhistiating mfonnation e«hai|ge between tile tei^ 
and die central server during a pollmg opeiation; and 

Fig. 9 is a flow diagram IUustrating operation of die server for handling 
mfoiraation feom die second embodfaneu of temtinal. 



25 



The principles used m tills embodhnem are first described briefly witii reference 
ioRgs.land2. TTieqwtemconsisisofaphindivof remote tamfaab 10 locaied. for 
example, m shops and/or banks whhm a local commmdty. The teiminals 10 
communicate whh a central processor, also referred to heremafier as die server 12. 
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The tenninals 10 may, for example, be coupled to the server 12 by conventioiial 
telq)hoiie modems wludi call up the server 12 to be cwtroUed by the server 12. In 
diis embocfiment, all opendxms ami caicolatibiis are performed by the server 12, and 
Ae teiminal 10 acts as a damh slave unit, i.e. as a ram>te inpat and diq>lay device. To 

5 iiq>i0ve security, the server 12 may call-back ti^ tennmal 10 at a pre-cfesigDated 
telephone mmiber to ensure tint third parties camiot break into the server operatkm. 

When a ww customer desues to perform a transfer, or desires tt> be 'logged'" 
as a customer for future transfers, this can be ^ne at any terminal 10, which calls the 
s^er 12 to perform tte process under to server's control. The cu^omer's details 

10 inchidmg his name and address are inputted dirough die temunal 10 and recorded by 
die server 12 m a customer database 12. The local agent gives the customer a swipe 
card (not shown) which may be coded in any suitable manner, for example, apdcaXty^ 
magnetically, or carry an electronic circuit In this embodhnent, die swqie card has a 
conventioiial magnetic strip on wluch is a pre-recorded code uniquely icfentifjing the 

15 card. Tte code also doubles as a umqne idradfication code for tte cnstcuner (and is 
refenedto later as the CIC, for customer- or card- idmdfication code). TovalUatedie 
card, ib& customer or die local agent is required to insert the card into the tenhinal so 
that die pre-recorded co& can be read by the terminal's card reader (m>t shown) and 
communicated to the sender 12 to be recorded in the customer database. 

20 Qtfaer hnmediately, or at some dme later, the senrer 12 aUocates a partjr 

uieadficatkm code (HQ for the new customer. The FIC is needed later by a transferee 
to verify diat he has been audiorised by the transfoor to receive die fimds. in dus 
fiPbo^T^j^t, the PIC is gwerated using a random or psendo random generator, and 
ccmsists of a intmmc code, for example, a four digit code, but an alphasnm^ or 

25 purely alphabetic code couM be used msiead. Hie FIC is printed using a secure postal 
ininter 16, and is posted direcdy to die customer 14. A significam feature is diat die 
FIC is not commnmcated through the terminal 10, and so the tocsd agent has no means 
of accesang a person's PIC to fr audule n tly iniercqfyt tiamfers. 
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To peifoim a transfer, the CDsttHner (transferor) 14 presents Us swipe card to be 
insened into the tenmnal's caid leader. This imdates conmnmicadon between die 
teimina] 10 and die server 12 so diat die transfer details can be inputted to die seiver 
12. llw transfer detaibinclode die name and address of die tiansferee, die amoont to 
5 be tnnsfeired. and die name and address of die banic or odier money handling andio^ 
at which die transferee win collect die txansferred funds. The latter Infonnadon can be 
selected fiom a list or menu of allowable collection andioiides for any particular 
oonntiy ortown. 

Hie server 12 calculates die amount required to be paid by die transferor, which 
10 the transferor pays to die local agent. Hie server 12 dieo allocates a transaction 

Identification code for die transfer, hi die foim of a unique transaction code (UTC). In 

dils embodhnent, die UTC Is based on a pseudo-random code, which is tested to ensure 
tint it uniquely identifies die transfer (at least for die period m which die transfer Is 

valid; die same code is avaihdile for re-use after diat period). Hie code Is numeric, but 
15 matternativeanbodhtteats could be alphanumnk, or purefy alphabetic. Thes^erl2 
c ommuni c at e s tiie UTC to die tennhal 10, and a hard copy of die transfer details, 

hKfaiduig die UTC, is printed out by die tenninal 10 to be given to die bansferor as a 
leceqM. 

It Is die transferor's responsibility to send die PIC and die UTC to die transferee 
20 18 and to ensure diat only die intended transferee receives thb mfonnation. Normally 
this would be done by sendmg die nc and die UTC by separate iDutes (depicted as 2()fii 
and 20b in Fig. 1), for example, by separate letteis, or by communicating one by leder 
and die odier by telephone or telex. The UTC and die nC togedier provide die 

transferee widi aU of die hdbimation needed to validate die transaction, and collect die 
25 transferred funds. 

To effect die transfo, die snver 12 commumcates a transfer request 22 direcdy 
or mdirecdy (for example dirough a remote temunal) to a computer 24 of a domestic 
bank (assnndng diat die transfer system Is behig ran by an fadgwaidcat organisation 
usugdiebankasanintBnnedhuy). Ihe transfer request 22 mchides die transfer details 
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sof^lied by the traiisferor» ami also ioclodes tte PIC and a transactioii verificatkm code 
(JVC). The TVC is related to die UTC to enable verificadcm of die conect UTC when 
presmted by the transferee, but die TVC does not itsdf craiain SQ£&aent infocmadon 
to enable die origmal UTC to be deduced if it is not Icnown. Hie banic conqxiter 22 
5 processes die transfer retpiest and commmikatBs the transfix infimnation 26» by 
OMiventional banic transfer services, for exanq^le by telex, or by SWIFT, to die foreign 
bank 28 ncminaled by tlie original instroctions fiom At transferor 14. The transfer 
infonnadon 26 sof^lied to the foreign bank inchides tl^ PIC and die tnuuated TVC. 
In order to collect die transferred fends, the transferee 18 viats the foreign bank 

10 28 and presents the PIC and fuU UTC. The PIC provictes evidem^e tliat the person has 
been authorised by the transferor to recnve fimds, and the fell UTC provides die 
necessaiy autfaorisadm to complete die tnmsaction. The staff at die foreign bank 28 
are able to compare transferee's UTC widi tiie TVC with which diey have been 
siqjplied to verify tliat die fedl UTC matdies the TVC. The foreign bank 28 dien 

15 returns the foil UTC to tte domestic home bank 24 as evidence that the transfer has 
been pnqperiy completed, and that the conect recq>ient has bem paid. 

Such a sysim offera impoitam advantages over craventional techniq^ 
(a) The transferee does not require any fonn of personal identificadon, such as a 
pasqpoit, or a driving licence. 

20 (b) The only paities in possession of all of the necessary information validly to 
complete a transaction are tte transferor, and the transferee. The agents at the point of 
sale (10) do not have access to die PIC, since this is allocated dinictly by the snver 12, 
and is communicated to die transferor by post Tte staff at the dmnesdc home bank 24 
and at d^ foreign bank 28 have access to the PIC, but do not have access to die foO 

25 UTC. Thig will obstmct any fi andulmf activity hy thft handBng mthnritiiMa ^gp^ 

(c) It is die lesponsibili^ of the transferor to transmit die PIC and die foil UTC to 
the transferee in a secure manner. If this infomudioQ is intercepted and the fonds are 
collected fiandulendy by a thin! party, tten neidier the money handUng authorities, nor 
the money tran^r organisaticm, has to accqyt liability. 
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For sabseqnent traosfeis ftom the same transferor 14, the briginal MC is 
reused, "nie server U maintains a database of tninsferon and the PIC al^^ 
each. New PIC'S are only allocated, ittinled and posted 
transferor believes bis PIC to have been compromised. 

In general, a transferor wiU only have to notify Ms PIC to a transferee once. 
Once the transferee knows the WC. aU he needs to leceive fends is the new UTC 
associated with each mdividnal tramacdon. Hiis further reduces die chances of 
information being intercq>iBd between die transferor 14 and die transferee 18. 

Hicre are numerous techniques for generating a TVC whidi relates verifiably to 
die UTC but does not prejudice die security of die inc. For example, one techniqDe 
is to truncate, or blank, one or more digits or diaracteis fiom die UTC. leaving a code 
which partly matches die fuU UTC. Hie security can be hnpnnred by varying die 
mmiber and/or die positions of die blanked characters, so diat a person will not be able 
to predict which of die characters of die code are already known m die TVC. 

Anodier technique for generating a TVC is generate one or mcne chedcsum 
digits or daracters. Tliese can cidier be inchided m die UTC. or diey can be inchided 
only in die TVC. TT« security can be hnpioved by varying die number and/or die 
pwdtions of die characters or digits on whkA die checksmn is based, so d^ 
will not be able to predict which characters rqjrcscnt. or contribute to. die chedcsum. 

In a paniculariy piefisned embodiment, die TVC is generated by a combination 
of die above two techniques. Referring to Fig 3, die UTC can consist of a 7. 8, 9 or 

10 digit code, for example die code iUustraied in Fig. 3a. TTiis is based on a pseudo- 
random number, but lailoral such diat die smn of die firat four digits A is represemed 
somewhere m die last fom^ digits, namely in die first one or two digits B of die last 

four, or die middle one or two digits C of die last four, or die last digit or digits D. In 
die ilhistrated code, die sum (i.e. 8+4+5+9=26) is lepiesented hi die middle two 
digits C of die last four. 

Fig. 3b iUustiaics a first TVC whfch may be generated fiom die UTC. Hie 
TVC indudes some of die original digits, die missfaig digits bdng replaced by "Wank* 



SUB8TmiTESHST(RULE26) 



wo 99/28872 



PCT/GB98Ai3537 



12 

dbaiacters. TTic TVC also imihides a prefix code **F*, or "L"* to imiicate whed^ 
thesiimistobefixiiKlmthel^st, MiMeorLas^ lathe 
present example, Ae som is in the middle digits C of the last fbor, and diis is dewted 
in the TVC by prefix "NT. It will be sqppreciated that Ae prefix code is only mcbded 

5 intheTVC, andnotindieUTC. 

When the UTC is presented for verifkadon, dwt local bank can cl^ firsdy 
whether the digits fat die UTC agree widi the digits already Imown in die TVC, and 
secondly, whedier d^ appfq)riate checksam digits denoted by the TVC's prefix 
con:eqx)nd to the sum of tiie first four digits. 

10 Hg. 3c illustrates a second TVC which may be gei^rated for the same UTC. 

Hie prefix code is, of course, die same as that for Fig. 3b, but diis exanq>le ilhistrates 
that a persm cannot predia which digits are known in die TVC, since this can vaiy. 

Hie above sdheme rqnesents a balance between secoiity and ease of veiification 
at a mnote bank. Other schranes may be used wh&di require ccmipoter verification, bi^ 

15 this could restrict die banks at whidi the transferee is able to collect the funds. 

Refeirittg to Rg. 4, the mnote unit 10 comprises a main {xtocessor 30 to whidi 
are ccmnected a di^lay scren 32, a keyboard 34, a swqpe card reader 38, a receqpt 
printer 40, a customer/transaction logger 41, and a telqihone communications nmlein 
44 coupled through an encrypdon/decryption unit 46 for communicating with the server 

20 12, The display screen may, for example, be a video diqilay unit, or it may be an 
alphatnitnte ric di^hiy, for example, an LCD di^lay. The di^lay is used to presmt 
messages and pronqyts to die custcmier (transferor) znd/or the local agent siq)ernsii^ 
die remote terminal 10, in reqxmse to instructioDS fiom the server 12, The details of 
die transacdon and, if the customer is a new cnstmnor, die customer's details, are 

25 entered using the keyboard 34. 

Hie loggm* 41 provides a summary of information iiqmtted through the tenninal 
10 durii^ a woridng day, so tliat end-of-day infonnadon can be gmerated and checloBd 
by the server 12. 
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The logger 41 and ite encrypdon/deciyptioii unit 46 are Olostiated above as 
disoete miits for ease of descripdcm. Ifowever, it will be j^^necialed that these onils 
may be embodied by software innnmg on the main processor 30* 

Refeiiing to Fig. S, die server 12 consists grimily of a cratral processor unit 
5 90 to which are connected a customer database 92, a tiansaction database 94, a 
reference database 96, a PIC generator 98, a UTC/TVC generator 100, a secure postal 
printer 102, an oo^t systrai 104 (for passing transfer instnicdons to a bank 
computer), an iiqnit cache 106, and a telq>hotte nuxfem 108 connected through an 
encryption/dcciyption unit 110 (which is similar to the encrypdon/decryption unit 46 
10 described above for the remote tenninal 10). 

The customer datatose 92 is a master database of aU customers (transferors) 
who have used the system at any tune. For each customer, die database also mchides 
full name and address mformaticm, at least fimited transacdon history, and the 
cnstxHuer's PIC and CIC. Hie transactkm database 94 is a master database of die 
15 transactions. This inchides aU pendmg transactiiHis, and possibly at least a fimited 
history of completed tnmsactknis. The infonnation m the transaction database 94 may 
be arehived ftom time to time to make more mraiory awulable for new transacticms. 
The reference database 96 is a master dat^>ase of die current referemre infonnatkm 
required for die transactions, inchidmg, for exan^)ie, die countries to which transfers 
20 can be sent, available recipient bank details for each country, cunency exchange rms 
and commis^non rates. 

The secure po^ printer 102 is of a known type wludi is able to produce sealed 
envelopes cantainmg a printed sheet, it being possible to read die sheet only by 
breaking open the seakd eiwelope. Such prinim are used hi applications where it is 
25 deared to print mfonnaticm securely to sad to a mapimt, while ensuring tfiat local 
staff are unable to read the ccmtents of die envetope. 

Hg. 6 iUttstrates die operaticm of die server 12 once commnnicaticm has been 
established betwem a tmninal 10 and die snver 12. Step V22 detenmns whedier the 
infonnation from the tenninal 10 corre^nds to a new or existing customer. This is 
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qjpaioit if tbe mfonnatioii contains an existing customer identification code QC. 
Assuming as a first case diat the information does cone^xnid to a new cnslomer* dien 
die process proceeds to stq> 123 at which tlie server 12 controls the tenninal to pn»qK 
for» and return^ uqnitted customer infonnation* ii^hiding the costomer^s lull mme and 

5 addiess. Atstq> 124 a new customer ratry is created in the costomer database 92. 

From stq) 124, tbe process proceeds to stq> 125 at which tlie senrer 12 controls 
tte tenninal to prompt for a new swfpt card to be introduced into the terminal's card 
reader 38. As e:q>Iained heieinbefore, die swipe card carries a pre-recorded QC^ wliidi 
is lead by die tenninal 10 and retuined to die server 12. At step 126, the read CIC is 

10 recorded m die costomer database. Tins completes die introdncdon of a new customer 
at die terminal 10. The customer can then use the swipe card to inithde a tnmsfer. 

At stq) 127, a PIC is generated for the mw customer by the PIC generator 98. 
As e3q)Iained previously, PIC is used later by die recq>ient to idratify hunself at his 
local bank to collect die transferred fonds. A separate PIC is generated for each 

15 customer. In the presrat embocfimrait, the PIC is produced as a random or pseudo- 
random 4-digit number, so that it is inoipossible lo derive any reladonship between the 
PIC and die customer's details (which might odierwise liable PIC*s to be predicted by 
firandulent parties). However, in other raibodimrats, die PIC ccmld be the result of a 
checksum or hashing fonction carried out on tte customer's name or address, so that it 

20 is possible to verify whedier given PIC matches given party's name. Alternatively, it 
is possible to generate a pseudo random PIC using an encryption algorithm whkh is 
vbtually hnpossfole lo reverse or to predict, but which re^ms a verifiable relationshqp 
widi the parties names. However, in the present embodunent, it is assumed diat it may 
be difficult to arrange for verificadon of tbe PIC by the recq>ient's bank, and so it is 

25 jneferred to utilise a ccmipletely random PIC. 

At step 128, die PIC is recorded in the costraner database. The PIC is also 
printed in a sealed envekipe by tte secure printer 102, and the eawtopc is addressed 
and posted to the customer at his hc»ne address identified m die customer informatioii 
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received finom the ranote tennioal 10 (and now stored in the customer <fataba«? 92 of 
Ibe server 12). 

It will be appreciated tbat steps 127 and 128 can be canjed out eitber 
immed ia ie ty after commnntcation widi the tmninal 10^ or at some subsequent time 
5 wben tte server 12 may be less busy. 

If at stq> 122 die received infoimation contains an existing CIC (and therefore 
coireqxmds to an existing customer^ die process proceeds to stq) 130 at which tte 
customer's PIC is retrieved from die customer database. At step 132, die transfer is 
analysed to assess whedier it is a suspkious transfer wliich should be stopped for legal 
10 reasons. Suspicious transfers may, for example, be detected as any of die followmp 

(0 transfers greater than a certain allowable amount (which may vary dqmdmg 
on the destination country); 

(iO repeated transfm whudi accumulate to a sum greater tfmi an allowable 
amonm over a predetermined pcnod (the amount may vary dqiradmg on die 
15 destination country); 

(iiO repeated transfers the frequency of whfch exceeds an allowabte figure 
(which may very depending on the destmation country). 

The purpose of stq> 132 is to provide at least a cfegree of protecticm to fwevent 
large scale money laundering or iltegd fimds transfer from one a If a 

20 stt^^icious transfer is detected, dien the transfer process can be aborted, or the server 
12 can pronqpt die terminal 10 dm proof of identification is required before tl^ transfer 
can proceed. Details of tl» proof of identificatkm (e.g. a passport numbw) can be 
entered at the terminal 10 for ccmnnunicaticm back to tiie server 12. 

At stq> 134, a chedc is performed on whedier tibie customer's payment has yet 
25 deared. If cash is used to pay for die transfer, dien dds slqp can be omhied. 
However, if payment has been made fay dieque, dien no transfer diould be andiorised 
until tte cheque has been cleared by die customer's banlL If die payment has not yet 
cleared, dien die data is re-stored (for example* in die input cache 106 or in a separate 
pendfaig store) to be re-imxessed during tte next day's processmg. 
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At Step 135, the UTC and the TVC for tte transfer are provided. These could 
eidier be genraated ''live*, for emqple, 1^ suitable algorithms, or die UTC and die 
TVC coaM be obtamed fimn a supply of jne-gmeialed codes. Such codes conU be 
pie-genrailed when the server 12 is not bnsy, for aanq>le, overnight, and stored in 
5 suitable nmnory. 

At step 136, the UTC is ccHnmimicated from tte server 12 to the tenninal 10 to 
be printed by die tenninal*s printer 40. This piovictes die costomer (transferor) widi 
die UTC to send to the transferee. 

At stq[> 137, the transfer details are issued as a transfer instruction to the 
10 intmnediary bank* The transfer mstiucticHis indude die transfer details originally 
iqntted by die cusbHnar, die PIC, and die TVC (inchufing die prefix code *F*, "M"^ 
or*L*). 

Atstq> 138, die transacdon details are stored m die transaction database 94 as a 
pencfing tnmsacticm, whidi completes the initial transaction processmg. Atdiough not 

15 iUustrated in the drawings, additional processmg can be provided wlm die foreign 
bank returns the foil UTC as evidence that tbc transaction has been coiiq>leted. The 
returned UTC can be conqnred to the UTC recorded in tiie transaction database to 
verify that tlie transacticm has been conq>ieted conecdy. Aheniatively, this verification 
step mi^ only be necessaiy if a transferor complains of non-delivery of fonds to the 

20 transferee, or of collection by an unauthorised person. 

In Fig. 5, the ^ryptkm/decrypticm unit 110, die nput cache 106, die PIC 
gBneiator98, die UTC gBDmm 100, die TVC gmerator 101, and die databases 92, 94 
and96are ilfai5tndedassqianue ''iieais* fromtfaes»verproce» Husisn^rdy 
to aid desnipdon of die hivention. tt win be ^qip^ parts may 

25 be itqdemented by softmre applicatkms immnig cm the processor. 

AUxm^ not ilfautrated in the drawings, it may also be possible for a cuslcmmr 
to pbce a teiqdioiie order to a telqihone receptionist, who would dien enter the transfer 
details using a dedica t ed tenninal^ or direcdy cm to the servo* 12. Hie UTC could be 
issued to die telephone transferor eidier by telqphone, or by means of the secure postal 
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primer 1Q2. In the latter case, it is prefened tlat the UTC be printed and posted 
separately team any c ommmiicatio n of a new FIC, to reduce the chances of these items 
of infotmatkm being fntw«^q»tpd togedier. 

The above embodiment enqdoys 'mline* opentiim of die tnminals 10 under 
the diiect control of the seivcr 12. All of die infoimatiQn processing is earned out by 
die server 12. Tliis can enable relatively ine]q)ensive and strai^itfbiwaid tenninals to 
be used, and it can also enable updated infonnation to be available immediatdy ainply 
by changing the information and/or the programs on the server. 

In an alternative onbodimrat. it may be desirable to provide at least some of die 
tenninals with a degree of autonomy, ftnr offlhie openoion. Referring to Fig. 4, die 
terminal 10 is similar to dot pievionsiy described, but mcfaides die foUowmg units 
(shtnm in phantom): a UTC/TVC generator 48; a reference database 36; and a 
custnmer/tiansacdon database 42. The reference database 36 piovides refeience 
infonnadon for die remote terminal, such as d^aJls of die imfividnal countifes to whidi 
transfers can be seat, and the individual banks in each country, die exchange and 
ccmnnission rates for eadi coomiy, and die likely transfer delay for each country (if a 
cakaladon of die expected arrival date of die fonds is to be providetO. The refermce 
database may also incfaide details of public holidays in each country, and die allowable 
methods of payment by die customer (for example, cash, cheque, credit card, e-cash, 
mondex, etc.) and the clearance delay for each type of payment (if die «iimiari>«, of 
die expected arrival date of die fonds is to be provided). Hie mfonnatiwn in die 
reference database can be updated periodically by die server 12, for example, at die 
start of a day. or during roudne poffing of die terminal 10 by die snvn; as described 
fordier below. 

Hie cnsiomer/tiansacdon database 46 is used to store details of transfer 

requests, and detaite of any new cusiomm, mitil the inftmnadon can be iqiloaded to tte 
server 12 finr action. 

Referring to Hg. 7. before a new customer can use die transfer ^siem, the 
cusiraner's doails have to be entered into die mminal nsmg die k^board (step SO). 
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Tbe customer (teails include the custoiner's name and address (or other contact 
deiaikX so that the secore PIC can be sent later to the cnstoinerb^ Tbt 
costDnra: details are ih» sttnred in the castom»/transactioii database 42 (stq> 32). 
Thmafknr^ the costcmier is issued with a swipt can! (step 54) whk:h canies a md^ie 

5 costDnieridentificadonoode(QQ^ase3qplainedprBvioosly. 

At stq> 56, the costCMner (or the local agrat) raters details of d» desued 
transfer. Swrh details include tl^ joame and aikbess of tte recipirat (transferee)* the 
anKmnt to be transferred (in die local caxmxy of the customer), medxxi of 
payment by die customer, and die destinaticm country, name and address of tbe bank or 

10 od^ money handling agent at whkh the recqnent will collect the transferred funds. 

At5tqp58, the processor 30 calculates and displays the vahie of the funds fa die 
re^ient's currmcy, and the amount of commisaon charged, based on the infonnaticm 
sumd m the refoence database 36. If desired, die processor may also calcubte an 
esdmated date of arrival of the transferred fimds at die destination bank, usmg 

15 information in die reference database, and die following fommla: 

Arrival dale — today's date -h fimds dearance dday + transfer delay + calendar 
(hcrfiday) delay 

20 If die customer agrees to die transactk>n and makes payment to the agent, then 

this is ccmfirmed at stq> 60. (If die customer declines to proceed, then the process can 
be abwted at this siq>.) Ihereafter, at step 61 die UTC and TVC tot die tran^r are 
piovicfed/graerated by the UTC/TVC genoalDr 48. Tbt UTC and TVC can ehher 
being geneiaied ""ttve"* or a pre-genoated UTC and 7YC can be retrieved. Such 

25 UTC's and TVC's may eidier be gmmied by hical generators widun die terminal, or 
they may be downloaded fitom die servor 12 as part of the iqidatB mfbrmatkm for the 
reference database. 

At step 62, die transfer details inchicfing the allocated UTC are stored in the 
cusiomer/transactimi database 42 to await iqitoading to the server 12 for processing. 



SUBSTITUTE SHEET (RULE 26) 



W099/28872 PCT/CB9»(OS37 

19 

Hie transfer details including the UTC are also printed out (step 64) by die tenninal's 
lec^pt piiDier 40 to piDfvide a receqtt for titt cosloiner. 

The above metfud steps apply to a new costomer. An edsdng customer simply 
insem his or her swq)e caid into die tenninal's caid reader 38 (step 66)» at 
die customer nnmber is read from die card. Tliis provides snifident infonnation for 
die seiver 12 to access die customer's details which are stored in die server 12. After 
siqi 66, die process proceeds direcdy to st^ 56 for die customer (or agent) to enter die 
details of die transfer, as described above. 

At various intervals during die day, die tenninal 10 is polled by die server 12 1^ 
teMiQoe, to upload money^tiansfer infonnadon and new cnstoner infonnadon to die 

senwr 12, and to receive new reference infonnation fiom die seiver 12. Refeningto 
Kg. 8. when a tekpfaone caU is received from die server 12 (step 70) die process 

proceeds to Step 172 at which dte tenninal 10 verifies diat dte can is from dte proper 
server 12, for example, by means of a secret password. Hie teiminal also ledmu a 
secret password, so diat die server 12 can veiiiy diat it is conummicadng widi die 
proper temilnal 10. It will be appreciated diat aU Infonnation sent and received 
duongh die telephone Une Is communicated m encrypted form, so diat die mfonnation 
cannot easily be intercepted. At die temunal end, die infonnation Is 
encrypted/decrypted by die encryption/decryption unit 46 connected between die 
processor 30 and the modem 44. 

Followmg Step 72, die tenninal wahs to receive aiiy new reference ii»fam..A« 
(step 74) for die reference database 36. SnchnewhifoanatioBraaybefaitftefoimofa 
replacemcm -refcnaoce- file to oveiwrite dte entire existing oonteais of tfte lefereace 
database 36. or it may be m dw fonn of update -packets' to replace on^ ceriahi 

infonnatian in die reference database. The new fadbnnatiai (if any) is dien written mto 
the database. 

At sl^ 78, dte tanunal transmits die new contento of dte cnstomer/tiansacticm 
database 42 to dte server 12. This new udbnnation mcfaides details of any new 
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cnstCMiieis (including the customer identification number for each new costomerX and 
details of transfer requests entered by the customersL 

Step 80 determines wliedier the tmnnial has dosed at the end of the day aml» if 
so, die process proceeds to siq> 82 at which od-of-day (EOD) informadon is 
transmitted to tlie server 12» The EOD information mdudcg totals representing the 
day' s transactions and new customeis, to provide a crossHdieck diat aO of die temdnal' s 
informadon has been validly received by die server 12. This is subsequ^idy cross- 
checked by the server 12. If die terminal has not yet closed at die end of die day, dien 
the process branches past stqp 82, to step 84 at which the comnumicadon is terminated. 

The server 12 will normally poll each terminal 10 at several differrat dmes 
during the day. During each commmiicadon sesaon, the te rminal transmits only the 
new informadon contained in the customer/transaction database 42 (Le. the informatioQ 
not previoosfy comimmicaled to the server). In this anbodiroent, die informadon 
moains in the customer/transaction database 42 until after die server 12 verifies, for 
oample, by means of the EOD faiformadon, diat all of the inlnmiati^ has been 
iqploaded conecdy to die server 12. Sucha technique enables all of die mformadontt) 
be uploaded to the server again if necessary, for exanqple, should any disaqwicies 
arise horn the EOD information. However, in ddier embodimmts, the 
custxmier/transacdon database 42 could be cleared after each conununicadon session 
with the server 12, if desired. 

In Fig. 4, die refermce database 36, die customer/transacdcm database 42, d^ 
ODcrypdcm/decrypticm unit 46 arKi the UTC/TVC ^aerator 48 have been iUustrated as 
distinct "items* fiom the proce^r unit 30. This presentation is merely schematic to 
aid descnpdon of the invradon. It will be sqiprcdated that such items may be 
implaoented as sqiplicatkm software run by the processor unit Hie r efer e n ce 
information and die cnstomer/transactioii information may be stmed as files on 
cconmdonal mass storage, for oanqple, a semiooncfaictor mass mraiory or a magnetic 
disc. 
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In use. the server 12 polls each remote terminal 10 to download updated 
reference infonnatkm lo the teimma] 10, and to upload new tiansferieqaest 
information and new-cnsiomer infotmaiion finm the terminal. The c«n.mmA.»A^ 
procedure is con5)lemenlary to that descra)ed above with refeieaice to F^^ 
not expanded further here. The uploaded information is stored temporarily hi the mpnt 
cache 106 untU it can be processed by the ptocessmg unit 90. 

Fig. 10 mnstiaies the manner m which each -packet" of information fiom the 
hipot cache 106 is processed. Where appropriate the same reference numerals as those 
m Hg. 6 are used to denote an eqnivalem operation step. Hie information is firsdy 
read from die cadie 106 at step 120 and, as before, step 122 determines whedier the 
information corre^wnds to a new customer. Assuming as a first case that the 
information does correspond to a new customer, then the process proceeds to stq» 124 

at which a new customer entry is created fa the oistomer database 92. comahifa« the 
CIC read fiom die input cadie. 

From step 124. die process proceeds to step 127 at wMch a HC is generated for 
. the custraner. 

At step 128, die PIC is printed m a sealed envelope by die secure printer 102. 
and die envehjpe is addressed and ported to die customer at his home address id^ 
fa die customer faformadon receded from die remote teimmal 10 (and now stored m 

die customer database 92 of die server 12). Tlie PIC is also stored fa die customer 
database 92. 

Stq) 132 represents die first step for processing die transfer after die customer 
and iecq>ient detaDs have been stored. At step 132, die transfer is analysed to assess 
wbedier it is a suspicious transfer which should be stofiped for legal reasons, as 
e^laiiKd m more detail hereinb^re. 

At step 134, a chedc is performed on whedier die customer's payment has yet 
cleared. Assumfag diat die payment has cleared, die process proceeds to step 136 at 
which die transfer dciaib are issued as a transfer instruction to die iniermediaiy bank. 
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He transfer instmcdcMis include die transfer details originally iqputted by tbe CDStomer, 
the PIC, and die TVC received finom he terminal 10. 

At Step 138, die tiansacticm detaib aie stored in die transactkm database 94 as a 
pemfing tnmsactkxn, which conq)letBS die initial tnu^ 
5 If atslq> 122, themfoiinationcQrre^imdstoanaistn^ 

proceeds to dinm^ step 142 at whkh ^ exisdng FIC for die coslomer is read fiom 
. ibt costomer database for re-use. The process then proceeds through step 132 for 
processing of die transfer details, as described above. 

In die above raibodiment, tte UTC and TVC are allocaied to the transacticm at 
10 the point of sale tenninal 10, to provide offline operation of die tenninal 10. Afthou^ 
in die ilhistraied embodimot, die TVC is allocated at die tenninal, this could instead 
be allocated by the server 12, to reduce the risk that die TVC migjit be available by 
t^qiping into die tenninal somehow. 

In the above embodfanents, the PIC is associated cmly with die transferor. In an 
15 alieinative form, the PIC could be associated instead with eadi transferar/tcansfeice 
pah*. Tims instead of a transferor bavmg a PIC, the transferor would have 
difiimnt PIC's for his cfififermt transferees. Tliis could provide aHfistgomti security if 
needed, but mi^ require the transferor to ranember possibly a large number of PICs. 
The customer database would also need to store all of the PIC's for each transferor, 
20 and be able to i&atiiy subsecpent transactions between the same transferor and 
transferee, in order to use the conect PIC. 

In d» above embodimrats, swipe card is pre-programmed widi its QC, ami this 
is the cmly informaticm recpured to be read by tltt terminal. In other mbodlmfiBts, the 
tenninal migttt be eqpiipped widi a canl readerAmter for writhig infonnatioii to die 
25 card as wdl as leading it fiimi the card. Tliis could enable T&vouritB rec^inat"^ data to 
be stored on the swipe card in order to slmpliiy the operation for die transferor. 

It will be appredated diat the unrention, particularly as illnstrated in die 
piefmed embodhnents, can enable fends to be transfened m a logical and secure, 
manner, whfch allows a recq[>ient to receive the fends without havmg to have oificial 
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proof of ktemity (such as a passport). Only the tnuisferor and die mtended transferee 
tmc access to sufBdeiit infonnadan to compleie the transfer, and it b the transfemr's 
le^onsibility to ensure dot the infonnaticm is sett m a secure 
Neidier die local handling agctt for die transferor, nor die local liandl^ 
transferee, liave direct access to sofiBdett inforaiadon to conq>letB a valid t^ 

While feannes believed to be of importance have been identified in die 
foregoing descripdon, and m die qipended claims, die applicant claims protecdon for 

any novel idea, feature or combination of feamres described herein and/or ainstrated in 
the drawings iirespective of whedier emphasis has been placed diereon. 
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CLAIMS 

1. A method of handltng moD^ tnmsfer le^^sts in a system which inchides at 
leasi one iapat device for leceiving infonnadcm directly or indirectly fiom a transferor, 

5 and processing means for conununicatmg with the iopnt cfevice for processing mon^ 
transfer reqnesls therefrom, the metiK)d conq>iising: 

receiving at tte processing means a money transfer request from Ate iqput 

device; 

providing witiiin the processing means a first identifier code for die transfer 
10 and/or for at least one of die parties to the transfer; 

sliding the first identifier code diiectly or indirectly to the transferor if die first 
identifier code is a new code, die sendmg opeiation to the transferor being an 
indqiendent operaticm fimn the commnnicaticm with the iqmt device; 

ouiputtin g mon^ transfer instnictiras inchidmg at least a poition of the first 
15 identifier code or infonnadon related thereto; and 

communicating the money transfer instnicticms to a money handling audioiity as 
instructions to efifect die mon^ transfer, whereby the authmi^ of die transferee par^ 
to receive die fimds can be verified upon presentation of die first idmtifier code by tiie 
tran^ree party* 

20 

2. A method of c^ieradcm in processing means for processing money transfer 
requests, die m^liod comprising: 

receiving at the processing means information representmg a money transfer 
recpiest; 

25 providing within the processing means a first idoitifier code associated widi the 

transfer and/or with at least one or tlie parties to the transfer; 

sending die first identifier code directty or indirecdy to die transferor if die first 
identifier code is a mw code; 
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omputdng money transfer instmctions including at least a portion of the first 
idntifier code or Inibnnation rebled fliereto; and 

c ommunicating the money transfer instmciiong to a money hamrfiing «[rtt,ffri|y 

instructions to effect the money transfer^ wheieby the antiioriiy of tlie tiansfeiee party 

5 to receive the fimds can be verified upon presentation of tlM first identic 
transferee party. 

3. Ametiiodofconmmnicatinginfonnation with a tnmsfeior for a money transfer 
qKraticm to tran^r money to a trandeiee, the method com|>rish^: 

10 (a) receiving tnmsfer instruction mfoinuirion directly or mdiiectly from die 

transferor; 

(b) piDviduig a first idendfier code associated with die transfer and/or with 
at least one of the parties to the ttansfer^ die code bemg required by die transferee to 
conqjl^ the money transfer i^mratkm; 

" <c) omputdng or selectively omputdng die first idendfier code for 

commmiicatirai tn the ti ansfe ffwr 

wheiem m step (c) die first idendfier code is ouqmtted for confidendal 
c onmnmicari Mi to the transfeior independendy of Hut ammnnit^ti^ in ^ (a). 

20 4. A method according to chum 3. whercm step (c) conq>iises seleedvely 
ouqputdng die first identifier code if die code is newly aiinr^ifd 

5. A mediod acconlmg to claim 1, 2, 3 or 4, wheiem die step of providmg die 

first identifier code comprises selectively allocating a new Identifier code, or iB^ 
25 previoudyallocatBd identifier code. 

6. A mediod according to claim 5, wherem die party identifier code is assodaied 
widi the tran^nMT. 
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7. A method aoconfing to claim 6, whereiii the piocessiiig means ccnDprises a 
cfaiabase of txansfeiois, tbt database contaiiiing for each transferor the or a paity 
identification code associated dieiewith. 

5 8. A method according to any preceding chim» wherein the step of allocating a 
new first identifier cocfe conq)rises generating a random or pseudo rarulom code. 

9. A method according to any preceding claim, fortter conq)rising generating a 
second idendfier code associated widi the transaction, and ouqmtting the second 
10 identifier code to tte transferor, and wherein die step of goieradng ttie money transfer 
instructicms at the processing means comprises including a verification code rebted to 
die seccmd identifier code to enable die correct second idntification code to be verified 
when presnded by the transferee. 

15 10. A mediod according lo claim 9, whnetn the second identifier code is ou^tted 
to the transferor at the or a remote terminal* 

11. A method of handling mcMiey transfer requests in a systnn which includes 
processing means for processing money transfer requests, the method comprising: 
20 generating an identifier code associated wtdi a transfer request; 

outputting tte ictoitifor code for ccmimnnication to the transferor; 

ouqmtdng fiom d^ processmg means mcmey transfer mstructicms mchufing a 
verificatmn code related verifiahfy to the identifier code; 

commmnicating the money transfer instructions to a money hfttidiing auttority as 
25 msoncdons to effect the money transfer, whereby the antfioriQr of the transferee parqr 
to recnve the fimds can be verified at least partly upon presentatKm of the orighnl 
idratifier otxie matching die incomplete ccxie in the num^ transfer instmciicms. 
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12. A meifaod acconBog to claim 11, wherein die identifier code is based on a 
random or psendo landoin code. 

13; A metiiod accoidiiig to daim 11 or 12, wbeiein tiie money transfer leqnest is 
5 gmerated at a tnminal remote fiom die jnocessing means, and die idendfiv code is 
ou^potted at die lenninal for die transferor, 

14. A medwd of operation in a {nocessing means Ibr processing money transfer 
reqaests, the mediod conqnrising: 

10 recdving at die procesang means information representing a money transfer 

request; 

providing an idendfio* code; 

providing a veiificatioD code related veiifiably to die identifier code, die 
veiification code being insufficient to enable die identifier code to be deduced 
IS uiamlngnoDsly dmefiom; and 

oo^mttiiig finm die processing means money transfer instractions including the 
transaction verification code, for commnnlcatirai to a money handling antiwrity as 
Instractions to efibct die money transfer, whneby die audiority of die transferee party 
to receive fends can be verified at least paitiy upon presentation of die original 
20 identifieroodematdimg die verification code in die mmiey transfer instnictiras. 

15. A metiiod accoidmg to chum 11, 12, 13, 14 or 15. wherein die identifier code 

is generated aich dm at least one cfaanicter diereof represeitfs a fimction of one or more 
odier chaiacters of die identifier code, and die stq> of providing die verification code 

25 wHnprises geacrating a code compriang at least mie, hrt not alU of tfie chaiactera of 
die identifier code and hichidfaig mfiMmation mdicative of die poaitioa hi aaU 
co(te of said at least me character aod/or of saki one or more (rtter characters. 
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16* A medKxl accoiding to daim 15» wherein the characters in the identifier code 
aie muneiic. 

17. A method accoiding to claim 15or 16, wherem the fimction is a som fimcticm. 

5 

18. A mediod according to claim IS, 16 or 17, wherem the verificatim code 
comprises one or more blank characms rqxres^iting missing character or digit 
positions of the identifier code» 

10 19. A mediod according to claim IS, 16 or 17, wherein the function is based cm . 
characters in cme or more predetermined positions in die identifier code, and said 
information rqxresents tbt position in said notification code of the resolt of the 
fimction» 

15 20* A metiiod acconfing to any preceding claim, further compriang storing the 
eadi identifier code at the processing means. 

2L A money transfer sj^lem coiiq>rising: 

at least ont input unit curable to generate a money transfer recpiest in 
20 accordant with information from a transferor; and 

j»ocesang means for communicatmg with tlie or each iapat unit for receiving 
and im)cessing nxmey transfinr recpests therefiom, die pn)cessmg me 

nttans for providing a fist id»tifier code for the transaction and/or for the one 
w moie parties to the transfer; 
25 means operable to ouQmt first infonnaiion mchiding the first kkntifier code, to 

be comiWHiiicatBd diiecdy or indirectly to the transferor inc^iendently of the 
communication opmiAxm with tlie ispot unit; and 

means for ooqnitting money transfer uistnictions inctading at least a poition of 
die first idratifier code or mfimnation related thereto, for communication to a money 
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handling auttoriQr as instructions to efifect the money transfer, wi^xi^ the authoiit^ of 
a transferee party to receive the fiinds can be verified at least pardy by presentation dt 
the first identifier code by the transferee party. 

5 22. A system according to claim 21, comprising at least one remote iqmt unit 

23. A procesdng system for use in a mcmey transfer systm for processing nM)ney 
transfer requests, the processing system con^Hising: 

means for receiving information representing a moi^y transfer request; 
10 means for providing a fist identifier code associated with the transactioii and/or 

widi one or more parties to the transfer; 

n^ans operable to output first infonnaiion inchiding the first idmtifier code, to 
be communicated directly or indirectly to the transferor; 

means for oul|intthig money transfer instructions including at least a portion of 
15 d» first identifier cocfe or infi»mation related diereto, for communicatioii to a money 
handimgantiioriqr as instructicms to effect ti^imm^tnmsfer, wheidiy die amhori^ of 
a transferee party to recdve die fends can be verified at least partly hy ptf^gMitaH^^ ^ 
die first identifier code by the transfraee party. 

20 24. A system fw communicating mformation widi a transferor for a mcmey tiansfer 
operation to transfer money to a transferee, the syst^ comprising: 

means for receiving transfer instruction information cfirectty or indirecdy firan 
tte transferor; 

means for providmg a first identifier co<te associated whh die transfer and/or 
25 whh at least one of die parties to die transfer, die code bemg required by die transferee 
tocomplete the money transfer operation; and 

means for ommmmg die first identifier cndft for mnflrfi%ntlai cnmrntny^^ ^ 
the transfimr. 
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2S. A system aoconfing to claim 24» wi^iein the means ibr (m^ttmg mfbnnatimi 
tor the tfansferor comprises means for selectively oa^nming die first idaiiifier code if 
die code is newty allocated. 

5 26. A system according to daim 2U 22, 23» 24 or 25» wherein die means fcH* 
provufing the first identifier code comprises means for selectively alkxating a new 
identifier code» or le^^ising a pieviously allocated identifier code. 

27. A system accoiding to clahn 26, wherein the first identifier code comprises a 
10 party idntification code associated with the transferor. 

28. A system according to claim 27, wherein die processmg means cooqirises a 
d ataba se of transfoors, the database ccmtaining for each transferor tiie or a party 
identificaticm code allocated thereto. 

15 

29. A ^ysmn accordmg to any of chdms 21 to 28, whmm die means for allocadng 
a new first identififtr code coDqirises means for generating a code based on a random or 
pseodo random code. 

20 30. A system according to any of claims 21 to 31, fordier comprising means for 
gyrating a second icfendfier code associated with the transaction, and (mtpntthig the 
sccojkI identifier code to the transferor, and wherein the means for generating tiie 
money transfer instnicdons at the processing means conq>rises means for inniprftng a 
verification cocfe rdaled to d» second Meotifier code to enable die correct idendfier 

25 code to be verified when presented by a ttansferee. 

31. A sysmm Kconttng to clahn 32, whoein die secmid identifier code is ou^mtted 
to die transferor at the or a remote terminal. 
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32. A syston for handUngmoDey transfer ieqDests,c(wqn^^ 

at least one input device ftv lecnvmg transfer reqoest infeimalion dkectty or 
indirect fam a transfenMr, 

means for allo c ating an identifier code associated witii the transfer leqneat; 
5 means fw onqmtting tiie idnnifia: code for die transfenMr, die code being 

required a transferee to conq>]eie a vaUd sMni^ transfer; and 

means for providing a vnificadra code related to the Identifier code, die 
verification code being insufficient to enable die identifier code to be deduced 
tiierefiom unambiguously, 
10 means for outputting mcmey trau^r instnictions including die vaification code 

for communication to a money handling andioiily» as instractions id effect the money 
transfer, whereby die andiority of a transferee paity to receive die fimds can be verified 

at least pardy upon presentation of die origfaial identifier code matchmg die veiification 
code in die mmiey transfer instractions. 

15 

33. AsystemacconfingtDcIaim32, wherem die Identifier code is geneiated as, or 
Is based on, a landom or pseudo .randcmi code. 

34. A system according to claim 32 or 33, wherem die uiput device is a remote 
20 teiminal. 

35. A proceKmg system for processmg mon^ mosSbi requests, die « yf— f 
c(Miq>risiiig: 

means for receiving fflfonnation rq^teseatiiig a ffloo^ transfer reqaest; 

2S iiiems for allocating a transaction identifier code for commnnication directly or 

indiiBcdy to a tnnsfiHor; 

means for providmg a verification code SBfated to die transaction identifier c^ 
die verification code b^g msulficiem to enable die identifier code to be deduced 
unandilguousiy thMefrom; 
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means for on^nitting money transfer insoucdons inclndmg the veii&adon codb^ 
fx commmucation to a money hatiHiing aothority as instnictions to effect the monqr 
. transfer, wheid^ die audioiity of the tian^iee parQr to receive fimds can be verified 
at teast partly upm piesentation of the ori^nal ymdfier code matching die inconq>letB 
5 code m the moo^ transfer instrocdons.. 

36. A tmninal for receiving money transfer recpiests, and for comnnmicatmg 
transfer recpest mfonnadon to a central pnx:es5or» die terminal compriang: 

mpot means for receiving infonnadon regarding the transfer ami the parties to 
10 the transfer; 

means operable to allocate and/or to receive a transaction identifier code; 
means for on^iuttmg the transactimi idradfier code for communication to the 
transferor; 

means for storing infonnadcm rehtfing to the requesied mcmey transfer, said 
15 mfonnatiop mchidmg the allocated idoitifiCT code; aikl 

means for comnnmicating widi a said central processon 

37. A terminal according to cfadm 36» whorein the hqput device comprises a caid 
reader for reading infoimation on a card presented thereto. 

20 

38. A terminal accordmg to claim 37, wherein the card reader conqirises a magnet^ 
card reader. 

39. A mediod of handling a money transfer request, compriang: 

25 receiving transfer request informadcm direcdy or indirectly fiom a transferor; 

allocating a transacdkm idendflcation code for die tranafo* reque^ 
providing a paity identifier code associated with one or more parties to the 
transaction; 
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commimicatnig at least the transaction identifier code to die transferor, to be 
foiwaided by tlie tiansfeior to die tranisfoce; 

c ommuni c atin g money transfer instracdoos to a money tatmrnn^ andioiity to 
effect die transfer, die money transfer instmcdons including infoimadaa relating to die 
transacdon identifier code and infoimadon relating to die party identifier code, but at 

least one of die codes Ijemg incomplete such dm die money tiansfer instnictions do not 
contain sufiBcieiit infoimation to comi^ete a valid transfn; 

whereby die andiority of a transferee to receive die fimds can be verified by die 
money handling amhority upon presentation by die transferee of die original tnnsaction 
idnidfier code and die origmal party falendficatioa code, which match die ndbimation 
m the money tnmsfiH' instnictions. 

40. A mediod accoidbig to daim 39, wfaerehi die step of commnnicatiiig 
rafocmadon to die transfoor comprises sdeetively conmumicathig die pai^ itiMirtiw 
code. 

41. A mediod accordmg to claun 40, wherein die step of commimicating 
infonimioB to the transferor amipiises comnnmicaiing die party idmdfier code if die 
party identifier code is newly allocated. 

42. A mediod accordmg to daim 40 or 41^ wherem die siqi of conmnmicaifaig 
mfonnation to the transfom* comprises not communicating the party fatimtww code If a 
party identification code has previously been allocated fiir an eariier transaction 
between da same parties, and is to be re-nsed for the current transaction. 

43. A mediod acconfing to any of dafans 47 to 49, wherem die pai^ M>««ifii..Ain 
code, if c omm u nic a t e d to die transferor, is commmiiratfd hidependendy of die 
tnnsaction identifier code. 
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44. A method of testing infoimatioB provided by a txansfeiee for coUecdon of 
fiinds» die method ompri^ng: 

itceivmg tiansfer instmcdcms bK^uding a fiist paity idendfier code allocated to 
at least one of tlie parties to tiie tiansfer, and a seocnd transaction verification code 
related tt> a transaction identtfier code allocated to the transaction; 

(a) comparing the first pai^ idmifiCT code from die transfer instmctions widi a 
party icfentifier code provided by the transferee; and 

(b) comparing tte second transaction verification code widi a transaction 
identification code provided by die ttansferee. 

45. A mediod according to claim 44, farther conqnismg retnnung the transaction 
identification code to the issuing authority as evidence tfiat die transferee is andiorised 
to receive the fimds. 

15 46. A medKid accoidmg to claim 44 or 45, wherein die transacthm verification code 
contahis some, bat not all of the diaracters of die transaction identificatfon code, and 
die method ccmipiises conqMuring each known duuacter in the transaction verification 
code for equivalmcy widi a corre^nding character of die transaction idratifier code. 

20 47. A metliod according to claim 44, 45 or 46, wherein tlie transaction verification 
code incfaides information assodated widi the result of a fonction based cm oa^ or more 
characters of d» trai^a^icm icfentificatbn code, and the method conqnises te^iiig 
whedier the transaction identificaticm code presented by the transferee matches the 
function. 

25 

48. A mettKxi or ajyaratns for hamHing money transfer regnests, bring .snhstamfailly 
as herriid>efore described widi reference to any of die acccmipanying drawings. 
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